1. Field
The present disclosed embodiments relate generally to wireless mobile computing devices, and more specifically to power conservation in such devices via varying an operating frequency or online state of one or more cores of an application processor.
2. Background
Mobile communication devices including devices such as smartphones, tablet computers, gaming devices, and laptop computers are now ubiquitous. A common and ongoing issue with these types of devices is power management. Although advances continue to be made in the areas of battery technology and hardware efficiency, current mobile device power management techniques are not adequate to meet user expectations and will almost certainly not be satisfactory in the future.
The application processor (or app processor) in many mobile wireless communication devices (or user equipment (UE)) has a variable operating frequency, which can be lowered to conserve power. App processors are also starting to see multiple cores, thus allowing one or more cores to be idled or put into an offline state to save power. Both of these power saving techniques save power at the expense of processing power, an acceptable tradeoff when the app processor is not being fully utilized anyway. Traditional UE have the ability to tailor the number of online cores and/or tailor the operating frequency to the app processor's utilizing (or load requirement).
For instance, when a user visits a website, the browser typically downloads a root html document from a remote server. In doing so, the browser resolves the domain name server (DNS) and establishes a communication connection with the remote server. This process can take 2.5 to 3 seconds on a 3G network because the modem has to be switched on and brought back up. During this 2.5 to 3 seconds, the browser typically does not perform any processing, but rather waits for a response from the remote server. As a result, the app processor is lightly loaded. Yet, the app processor typically continues to operate at the same frequency, which is higher frequency than necessary to handle this light processing load.
The operating frequency and number of online cores (versus those in idle mode) can be reduced in order to better match power consumption to the app processor load requirement, but current methods of doing so are reactive—they occur in reaction to processor loading. For instance, a core controller (e.g., mpdecision algorithm) typically decides which cores to put into an online or offline state (or idled mode), and a governor (e.g., DCVS) typically controls the operating frequency of each online core (e.g., clock scaling). The core controller and governor monitor a load on the app processor, and in response, modify the number of online/offline cores and operating frequency of online cores to minimize power consumption. The trouble with this scheme is that the core controller and governor react to the app processor load and thus entail some delay before power consumption is reduced to a minimum level needed to meet the app processor load requirement.
FIG. 1 illustrates a block diagram of traditional software, hardware, and firmware components in a mobile wireless computing system 100. The block diagram includes applications 102 (e.g., a web browser) at the highest level of abstraction and hardware such as the applications processor 114 at the lowest level. The kernel 108 along with traditional interface 106 enable communication between the applications 102 and the applications processor 114. In particular, traditional interfaces 106 pass system calls from the applications 102 to the kernel 108. The governor and core controller 112 monitor a load on the app processor 114 and determine a number of cores 116 to operate offline (in idle mode) and an operating frequency to operate the online cores 116 at. For instance, the governor can be an “ondemand,” a “conservative,” or an interactive governor (for Android UEs), each of which periodically samples the app processor 114 load to determine whether to raise or lower the app processor 114 operating frequency. The governor and core controller 112 can then control the number of operating cores 116 and operating frequency of the cores 116 via the kernel scheduling module 110. As seen, power consumption of the app processor 114 can only be controlled after-the-fact—after a load has already been placed on the app processor 114.
Although the applications 102 (e.g., browser 103) can communicate with the kernel 108 via traditional interfaces (or APIs) 106 in the form of system calls, there is no way to communicate a load requirement of the applications 102 to the kernel 108.